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During the period of time from August 1970 through Jan- 
uary 1971 and while employing the TSS/36O Time-Sharing Sys- 
tem at this institution, it was observed by the user 
community that the performance of the system was poor com- 
pared to the previously used time-sharing system - the CP/67 
(version 3 , from Cambridge Research Center). For this reason, 
the problem of improving TSS/36O performance v;as undertaken 
as a thesis project. Specifically, the improvements consist 
of an Increase in system performance — responsiveness and 
throughput - by judiciously adjusting the parameters of the 

— - _ 4 _** UliCt 

Principles of Balanced-Core Time and V/orking Set Size. 

A number of test runs were made, and the results are giv- 
en, employing different schedule tables. A set of benchmark 
programs (or script) were developed and used with these tests 
that v;ere characteristic of a "typical" or "realistic" load 
at this installation. 
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I. INTRODUCTION 



Since the initial release of the time-shared operating 
system, TSS/36O, in October 196 ? , performance has improved 
significantly with each subsequent release. However, for the 
period from August 1970 to February 1971 , the Naval Postgrad- 
uate School converted from the CP/67 time-sharing system to 
the Time-Shared System, TSS/36O, and found the nev; system 
undesirable to the user community in terms of system perfor- 
mance - responsiveness and throughput. Because of its poor 
performance, TSS/36O was short-lived at the school and was 
never given an opportunity through testing and evaluation 
procedures to indicate its worth and future use as a good 
performance time-sharing utility. 

The objective of the research for this thesis v/as to 
find ways of improving the performance of TSS/36O at the 
Naval Postgraduate • School . 

After having read the available literature on the 
TSS/360 system, it seemed that the key area for study and 
work was the scheduling algorithm. At first a simulation 
model of the TSS/36O scheduling algorithm looked like a 
fruitful area of endeavor; however, this area v;as abandoned 
because of the time factor in building such a detailed sim- 
ulation model and since it had taken John McCredie and 
Steven Schlesinger of Carnegie-Mellon [Ref.l] about a year 
to write such a model. They describe a modular simulation 
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model designed to aid in determining the value of entries in 
the TSS/360 schedule table. They showed that a useful model 
can be designed to answer a limited set of questions about a 
complex system without detailed modeling of all system 
components . 

Another alternative, and the one that was finally pur- 
sued, investigated, and tested, was that of methodically 
altering the parameters of the TSS/360 Table-Driven Scheduler 
to achieve optimum system performance for the particular 
IBM 360/67 hardware configuration available. 

In order to test and evaluate the performance of TSS/36O, 
which was based on five test runs with different schedule 
tables, it was first necessary to construct a set of test 
nrogram?; (a benohmai^k or script ) that v/ould be representative of 
a realistic load on the system. This alone v;as a difficult 
task since, in a time-sharing environment, many user programs 
are in contention for similar system resources and at any 
particular -time , there could be many demands or requests for 
a particular resource. 

Another objective of this paper is to compile the avail- 
able literature regarding the performance of time-sharing 
systems that apply to TSS/36O and show by experimental tests 
that these principles and concepts improve system 
performance . 
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II. NATURE OP THE PROBLEM 



When this institution purchased the IBM 36O/67 computing 
system in 1968 , TSS/36O time-sharing operating system was not 
yet available (with the bugs removed), but the future em- 
ployment and Implementation of TSS was the big factor and 
sales promotion feature in purchasing the IBM 36O/67 hard- 
v/are configuration. As an alternate, CP/67 (version 3 from 
Cambridge Research Center) v/as used successfully for nearly 
tv;o years. Then announcement was made to the user community 
that in August 1970 the IBM 36O/67 would be operated as it 
was originally Intended and that TSS/360 would replace the 
CP/67 time-sharing system. Prior to implementation by the 
computer facility programming staff, the TSS/36O was debug- 
ged and tested; however, little consideration was given to 
tuning the system to the job load of the Naval Postgraduate 
School environment. 

As previously stated, the TSS/36O time-sharing system 
was used for about six months during which time the perfor- 
mance v;as quite unacceptable to the user community. It was 
observed that heavy paging users could ruin the performance; 
l.e., a few users manipulating large matrices or having 
many subroutines not properly linked could decrease the re- 
sponsiveness to the other users. It v;as for this reason that 
this thesis project was initiated and motivated. 
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The two basic approaches that have been used for investi- 
gation of existing time-sharing systems have utilized either 
the analytic or simulation techniques. The analytic approach 
was the technique used to improve system performance of 
TSS/360. By methodically adjusting the parameters of the 
TSS/360 Table-Driven Scheduler using the principles of 
Balanced-Core Time and Working Set Size, Improvement of the 
performance of the system can be achieved. Walter J. 

Doherty [Ref. 2 ] showed that the performance of Release ^ 
Schedule Table of TSS/36O at the T.J. Watson Research Center 
was dramatically Improved in a three-month period. 

III. PRINCIPLES AND CONCEPTS 

The principles and concepts discussed in this section 
are a compilation of the available literature regarding the 
improvement of performance of time- sharing systems as they 
pertain to TSS/36O. 

A. PERFORMANCE 

Performance, appraised by Callngaert [Ref. 3 ] as an inde- 
pendent entity, does not exist. The concept of performance 
can have a broad spectrum of meaning to different classes of 
people. However, fundamentally, performance of a computer 
is defined as the degree to which a computing system meets 
the expectations of the person involved with it. Some of the 
terms that are often Included as aspects of performance are 
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responsiveness, throughput, turn-around time, availability, 
reliability, number of terminals supported, CPU utilization, 
channel and device utilization, and efficiency. 

To a user of TSS/36O sitting at a terminal, the ability 
of the system to respond to his commands is his predominant 
view of performance [Ref.^]. A terminal user does not care 
if only one person or a hundred people are using the system 
simultaneously with him so long as the user thinks that 
there is a complete and dedicated computer at his disposal 
to provide certain services to hlmi. A user would be much 
more irritated if he expected a TSS/36O edit request to 
respond in three seconds but it took five seconds than if l.e 
expected a response of ten minutes to some complex mathema- 
tical equation but it took thirty minutes. In other woras, 
the system should be much more responsive to those requests 
to v;hich a user expects an Immediate reply, than to those 
requests during which the user kno’,vs that his attention can 
be turned elsewhere. (He could execute these programs in 
the background batch operation if the response is too slow. ) 
This was a primary assumption that was made while setting out 
to improve TSS/36O performance. 

It is most Important to a system manager to know the 
number of terminals that TSS/36O can support, and it is also 
important to consider the categories of work that the termi- 
nal users are doing. As Doherty points out in his paper, 
an intuitively obvious but rarely mentioned concept is that 
for some categories of trivial v/ork, the number of terminals 
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receiving adequate response may Increase only after a thresh- 
old of human performance is reached. In other v/ords , if the 
system is responding at a rate slower than a person's re- 
sponse time, any initial Improvements in system performance 
will first result in the user's getting more work done] and 
only then will the system be able to handle more users at 
that level of responsiveness. By allowing longer delays in"' ' 
processing long-running programs as the load Increases, it 
is possible to ensure that the very short jobs will constantly 
be provided with a fast response. 

B. FOLDING PROGRAMS 

Sayre [Ref. 5] states: "By the unfolded form of a program 
we mean the form a program would take if it had available to 
it a large enough uniform memory to hold both itself and its 
data.... On the folded forms the addresses have been rear- 
ranged — folded-to-f it into the smaller address space actu- 
ally available." In TSS/ 36 O, unfolded forms of programs and 
data exist in virtual memory. When a program is executed, 
portions of the program and its data are brought automatically 
into main memory for execution, which will result in automa- 
tic folding of the program if its complete execution space 
requirements are larger than the main memory available to 
hold it. McCredie [Ref. 6] expressed in his paper that exces- 
sive overhead and long delays while pages are transferred 
into and out of core are two potential dangers of paging 
designs. It is Important to fold a program into as small a 
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space as possible to prevent a degenerate situation called 
"thrashing" from occurring due to an unnatural folding. 
"Thrashing," as Denning [Ref. 7 ] states, may also occur when 
a page is pushed from core to make room for another, but then 
is demanded again and brought back into core. Many program.s 
can reach this state, and the paging rate can get so high 
that all productive v/ork ceases. It is important to main- 
tain a high degree of folding since it permits many programs 
to be folded into main core simultaneously, thereby providing 
a potentially significant increase in the level of multi- 
programming. The dynamic relocation hardware available on 
the IBM 360/67 makes the automatic folding concept possible. 

C. LOCALITY OP REFERENCE 

The program performance on any paging system is directly 
related to its page demand characteristics. A program whicli 
behaves poorly accomplishes little computation on the CPU 
before making a reference to a page of its virtual memory 
that is on back-up storage, and thus it spends a good deal of 
time in waiting for pages to be read into core memory. A 
program which behaves well references storage in a more 
acceptable fashion, utilizing the CPU longer before referenc- 
ing a page v/hich must be brought in from back-up storage. 

This characteristic of storage referencing is often referred 
to as a program's locality of reference and can be found in 
Brawn's and Gustavson's paper [Ref. 8 ]. Therefore, a program's 
locality of reference will influence the degree of folding to 
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which that program can be subjected with a minimal Influence 
on its performance. Doherty has shown that a program with 
good locality will run more efficiently in a small execution 
space than one with poor locality. 

D. WORKING SET AND WORKING SET SIZE 

P.J. Denning [Refs. 9 and 10] has investigated working set 
models with regard to program behavior in a virtual memory 
environment such as in the IBM 360 Model 67 . The v/orking 
set W(t,T) of a program is the set of pages referenced in 
the T page references immediately prior to time t. As time 
progresses, VJ(t,T) may or may not change; however, the 
better the program’s locality of reference, the less likely 
it is that W(t+1,T) W(t,T). From Denning's paper, it 

appears natural to try to fold a program in such a way that 
the program's working set for a given time interval fits 
entirely in core memory. Reports of Pine, Jackson, and 
Mclssac [Ref. 11] provide some experiment al evidence that 
the working set concept is a reasonable assumption for pro- 
gram paging behavior. Denning defines the working set size 
S(t,T) of a program, at time t, as the number of pages con- 
tained in the working set W(t,T). Therefore, it is possible 
to have the working set size remain unchanged and have the 
working set change. It appears natural to try to refold the 
program whenever its working set changes but, as Doherty in- 
dicates in his paper, it is difficult to do since it 'is not 
knov/n in advance just when the working set is changing. So 
in most paging systems, a v;orklng set size change is more 
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easily detectable; hence. It Is possible to detect working 
set changes at least when the working set size changes. 
Doherty describes a method for doing this, and his method Is 
outlined below. The dynamic relocation hardware of the 
Model 67 system makes the application of this concept 
possible . 

Using the concepts of working set, working set size, and 

locality of reference, Doherty states: 

"During a single interaction between a user at a terminal 
and TSS/360, several programs are usually executed for 
that user. Thus for the virtual execution time which 
spans this interaction, the working set size may or may 
not change; however, the v/orklng set will almost alvjays 
change several times. Furthermore, for those- programs 
having good locality of reference, the working set size 
during any one time slice will usually be much smaller 
than the working set size for the vjhole Interaction time 
Interval. And, in addition, the maximum v;orking set size 
for all the time slices will probably always be smaller 
than the working set size for the whole Interaction time 
interval. For those programs having poor locality of 
reference, the working set size for each time slice may 
frequently approach the working set size for the entire 
interaction time interval. Good locality relates more to 
the rate at which new pages enter W(t,T) than to its 
actual size." 



E. BALANCED CORE TIME 

From the previous discussion, programs having poor local- 
ity of reference and a large working set size would greatly 
reduce the level of multiprogramming if allowed to remain in 
core for very long periods of time. This result would affect 
throughput and responsiveness, since any new demands for ser- 
vice could not be honored quickly because core would be tied 
up. The Principle of Balanced-Core Time states that the 
length of the time slice in terms of virtual CPU execution 
time for any one task is inversely oroportional to the 
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working set size in that interval. Therefore, this concept 
will allov; good locality programs to progress very rapidly, 
whereas it will minimize the elapsed time that any large 
program (large working set size) can tie up core memory. In 
other words, a minimum time slice length v;lll then be set for 
programs with large S(t,T) and poor locality to prevent pag- 
ing overhead from dominating the system. In order to com- 
pensate for this compromise, the duration between large 
program time slices will be made much longer than the dura- 
tion between time slices for smaller working set size pro- 
grams. As a , result, the level of multiprogramming and 
responsiveness will increase since more core is available 
more often. In addition, the degree of CPU utilization will 
Increase. ^ 



IV. TSS/360 TABLE-DRIVEN SCHEDULER 

The table-driven scheduler [Refs . 12 and I3] is an algo- 
rithm which schedules and dispatches tasks within the multi- 
programmed, time-shared environment. More specifically, the 
scheduler consists of a set of programs in the resident 
supervisor of TSS/360 used for scheduling, and consists of a 
static and resident table consisting of a variable number 
(256 maximum) of 28 -byte entries. The 28 -byte entries are 
called levels of the schedule table of Schedule Table En- 
tries (STE) . Each entry in any one level of the schedule 
table contains sufficient information to completely control 
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the execution of a task. The format of the schedule table 



entry is depicted in Figure 1. 
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Figure 1. Contents of the Schedule Table Entry 
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Each task which enters the system has another table to 
describe itself to the system called the Task Status Index 
(TSI). Each TSl has a pointer to a level in the schedule 
table. Therefore, by changing the value of that pointer a 
task will be given a completely new set of scheduling 
parameters . 



'-t 



All TSl ' s in the system are chained together on one of 
two lists called the active and inactive lists. The active 
list has tv;o logical subdivisions called the dispatchable 
and eligible lists. The dispatchable list consists of 
tasks occupying core storage and wa.Lting for the .CPU, and in 
most cases, whose S cheduled Start Tim^ (SS_T) is less than 
the Master Clock (MC) . When the SST of a task is less than 
the Master Clock, the task is said to be behind schedule. 

Tasks in the dispatchable lists are ordered according to 
their status as "execute bound" or "1/0 bound." Those with 
heavy paging demands (I/O bound) are dispatched first. 

The eligible list consists of tasks which are availing for 
entry to the dispatchable. list , i.e., which are ready to exe- 
cute but have not yet been brought into main ' storage . These 
tasks are ordered by priority with the lowest priority number 
first on the list. 

The inactive list consists of tasks v;alting on long 
delay type stimuli, such as a terminal Interrupt. These 
tasks, which are in AWAIT or TWAIT status, are incapable of 
continuing execution until a particular Interruption occurs. 
Figure 2 depicts the m.ovement of tasks among these three lists. 
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TASK REACHES NOR- 
MAL OR FORCED 



TASK 

BECOMES 

DISPATCHABLE 




TASK 

LEAVES 

AWAIT 

OR 

TWAIT 

STATUS 



Figure 2. Maintenance of TSI Lists 



The schedule table controls the order in which tasks / 
are brought into the dispatchable list and the conditions 
under which the task will leave the dispatchable list. 

The fields of each Schedule Table Entry (STE) can be 
classified into six logical areas. 
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The first is a set of fields that control dispatching, 
i.e., the order in which tasks move from the eligible to the 
dispatchable list (STEPRIOR, STEDELTA, STERCMP). 

The second is a set of fields that provide limits that 
determine when a task shall be time sliced and leave the 
dispatchable list (STETSVAL, STEQUANT, STEMAXCR, STEAWTEX, 
STEPRMT) . 

Third is a set of fields that specify the level transi- 
tion that will be made when the respective limit or stimulus 
has been reached (STEPULSE, STETSEND, STEMPRE, STETWAIT, 
STEAWAIT, ATEHLCK, STELCHL, STEWLCK, STECV/0, STELCP, STEPRJ3, 
STENSL) . 

Next is one field which can stimulate a change in the 
order of tasks on the dispatchable list (STEMRQ). 

Fifth is a set of fields which allow the resident 
supervisor to release some of a task's pages rather than 
time slice the task (STEST, STESRI). 

Finally, there is a field which can override the system 
calculated drum share of private pages for a task (STEDSH) . 

Appendix A contains a description of each of the fields 
or parameters within a schedule table entry. 

A. STRUCTURING OF SCHEDULE TABLE ENTRIES 

By implementing the scheduling principles and concepts 
previously discussed, a wide spectrum of scheduling strate- 
gies can be implemented by altering only the entries \;ithin 
the schedule table. 
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In constructing the schedule tables according to the 
table scheduling strategies, diffei-ent sets of levels are 
grouped according to some primary goals of scheduling. 

Several particular programs (tasks) are treated differently 
than other programs, e.g., system operator task, bulk I/O 
task, logon, and logoff. Figure 3 shows an example of a 
schedule table. All other programs are divided Into the 
Interactive and batch categories. In general, the same sets 
of levels exist for both kinds of programs, except that Inter- 
active programs have priority over batch programs; that is. 
Interactive programs, initially, have a greater urgency to 
start than do the batch. The number of batch programs al- 
lowed to run simultaneously is arbitrarily restricted so 
that adequate space will be available for anticipated inter- 
active programs. The Interactive sets of table levels are 
grouped according to the following: 

1 . The Starting Set 

The starting set of table levels are used to handle 
new inputs from the terminal. The functions of this set of 
table levels are to facilitate a rapid reply to the terminal, 
if possible, and to make an initial judgment of the present 
working set size of longer running programs, so that the best 
entrance to the looping set of table levels can be chosen for 
the particular program. 

To accomplish this, several successive table levels 
with high priority, small execution time limits (100 milli- 
seconds), and increasingly larger core space limits (l6, 32, 



21 



'S 






L 


P 


T 


0 


n 


n 


P 


A 


0 


T 


n 


T 


A 


RP 


B 


K 


L 




P 


P 


P 


P 




f 


N 


S 


u 


A 


A 


0 


W 


f. 


s 


p 


W 


W 


CR 


P 


L 


C 


L 


H 


R 


R 


R 




V 


I 


V 


A 


X 


X 


L 


T 


L 


E 


R 


A 


A 


nn 


0 


C 


H 


C 


J 


J 


J 


J 




r 


O 


A 


M 


c 


H 


5 


E 


T 


N 


E 


I 


I 


PP 




6 


L 


K 


1 


2 


J 


9 




L 


R 


L 


T 


t 


D 


B 


X 


A 


0 




T 


T 


T 




















STSOPEPO 00 


OS 


0026 


01 


20 


Pf 


00 


0000 


00 


00 


00 


00 


00 


00 


OA 


16 


16 


2 J 


DO 


00 


00 


00 


STABTi 


liTERACTIVR D1 


1 B 


0010 


01 


10 


FF 


0 1 


0000 


00 


97 


SI 


JO 


00 


bO 


DA 


17 


17 


29 


IP 


IP 


IP 


IP 




IWTESACf 1* E 02 


Id 


00 10 


01 


10 


PP 


02 


DODO 


00 


97 


SI 


10 


OH 


HO 


OA 


1 / 


1 7 


29 


1 E 


1 P 


IF 


1 p 


SET 


INTERACTIVE 01 


1 H 


0010 


01 


ID 


PP 


0 t 


0000 


OD 


9 7 


SI 


to 


OH 


M ) 


0 A 


1 7 


1 J 


29 


IP 


IF 


IP 


IP 




I NT FR ACT IV F. DM 


10 


DO 10 


0 1 


10 


F P 


OR 


GOOD 


00 


97 


SI 


10 


OH 


MO 


0 A 


1 7 


1 7 


29 


IP 


IP 


IP 


1 p 




INTERACTIVE OS 


1H 


00 10 


0 1 


ID 


PP 


OS 


ODDO 


00 


97 


SI 


JD 


DM 


bO 


OA 


1 7 


1 / 


29 


IP 


If 


IP 


1 f 




INTERACTIVE OS 


IR 


00 10 


01 


10 


PP 


06 


0000 


00 


97 


S 1 


JO 


OH 


HO 


0 A 


17 


1 7 


29 


IP 


1 P 


IP 


IF 




I BTERACT If E 07 


Irl 


00 10 


01 


10 


PP 


0 7 


DDUO 


00 


r7 


SI 


10 


Ob 


bO 


UA 


1 7 


17 


24 


1 f 


1 P 


1 f 


1 P 




interactive or 


1 R 


0010 


01 


10 


Pf 


OH 


ODO-J 


00 


97 


SI 


in 


Ob 


to 


0 A 


17 


1 r 


29 


1 P 


IP 


IP 


If 




I NTERACT IV E 09 


IR 


00 10 


0 1 


1 0 


PP 


OR 


0000 


00 


97 


S 1 


to 


OH 


bU 


OA 


1 7 


17 


29 


IP 


IP 


IP 


1 P 




RULK I-O OA 


09 


0026 


0 1 


20 


PP 


OA 


0000 


00 


CA 


OA 


DA 


OA 


00 


01 


1 A 


11 


22 


0 A 


0 A 


0 A 


0 A 




BATCH OB 


10 


001 1 


01 


1 0 


PP 


0 b 


0 12P 


0 1 


RC 


IS 


IS 


DO 


HO 


0 A 


IB 


IB 


2 7 


OB 


OB 


OB 


OB 




BITCH OC 


ID 


00 n 


01 


10 


PP 


OC 


0 I2P 


0 1 


9C 


JS 


IS 


OC 


HO 


OA 


1 B 


1 B 


2 7 


OC 


OC 


OC 


OC 




BATCH 00 


10 


001 J 


01 


10 


f P 


on 


012P 


0 1 


OC 


IS 


IS 


00 


bO 


OA 


IB 


10 


2 7 


00 


00 


UO 


00 




BATCH OE 


10 


00 1 1 


01 


10 


PP 


OP. 


0 12P 


0 1 


9C 


JS 


JS 


OP. 


HO 


DA 


IB 


1 B 


2 7 


OE 


OE 


OE 


0 B 




BATCH Of 


10 


0011 


01 


10 


Pf 


DP 


D 12P 


0 1 


9C 


JS 


ts 


OP 


HO 


0 A 


1 B 


IB 


27 


DP 


UP 


UP 


DP 




BATCH 10 


10 


00 13 


01 


10 


PP 


10 


0 12P 


0 1 


9C 


JS 


IS 


10 


HU 


OA 


1 fl 


1 B 


27 


10 


10 


10 


10 




BATCH 11 


10 


001 1 


01 


1 0 


PP 


1 1 


0 1 2P 


0 1 


9C 


IS 


IS 


1 1 


00 


DA 


1 B 


1 D 


2 / 


11 


1 1 


1 1 


1 1 




PATCH 12 


1 D 


001 1 


01 


1 0 


FP 


12 


0 12P 


0 1 


9C 


IS 


IS 


12 


HD 


0 A 


IB 


IB 


27 


12 


12 


12 


12 




BATCH 11 


10 


00 11 


0 1 


in 


PP 


1 1 


0 I2P 


DO 


9C 


JS 


16 


1 J 


bO 


OA 


1 B 


1 B 


2 7 


1 i 


1 J 


1 J 


1 J 




LOfSON 19 


0 i 


002h 


02 


20 


PP 


19 


00)0 


OD 


19 


19 


' 9 


19 


00 


OA 


ID 


ID 


21 


19 


19 


19 


19 




LOGOP»> IS 


09 


0 0 2h 


02 


20 


FF 


IS 


0000 


UO 


IS 


IS 


IS 


IS 


bO 


OA 


1 E 


1 E 


20 


16 


16 


16 


16 




SrSOPEPO 16 


no 


00 n 


0 1 


20 


FP 


16 


0I2F 


00 


OD 


00 


16 


00 


00 


OA 


16 


16 


2 J 


00 


00 


00 


00 


HOLOlsr. 


INTERACTIVE 17 


02 


001 1 


01 


1 3 


FP 


1 7 


012P 


0 0 


97 


20 


1 7 


DH 


00 


0 A 


1 7 


1 7 


29 


IP 


1 p 


IP 


IP 




rsTEPACTIVE IM 


02 


00 1 1 


01 


20 


FF 


IH 


0 I2P 


00 


9B 


2fl 


’ a 


OH 


00 


UA 


111 


lb 


26 


IP 


IP 


IP 


1 P 


INTERLOCS 


INTERACTIVE 11 


01 


on 1 1 


4l 


10 


PP 


IH 


0 12P 


00 


9A 


2C 


1 'i 


OH 


OD 


0 A 


IS 


IS 


2h 


1 P 


IF 


IP 


1 f 




BJLA I“0 lA 


0 1 


OHI J 


01 


20 


i f 


1 A 


01 2P 


00 


1) A 


0 A 


1 A 


0 A 


0 J 


UA 


1 A 


lA 


22 


1A 


lA 


1A 


lA 


SET 


BATCH IB 


0 9 


00 1 i 


0 1 


10 


FF 


1.H 


0 1 2F 


cn 


9C 


IS 


IB 


on 


00 


(I A 


1 B 


1 B 


2 7 


1 B 


1 B 


1 0 


1 fa 




BATCH 1C 


09 


D01 1 


01 


U' 


?r 


ic: 


0 1 2P 


00 


ts 


J6 


1<* 


1 1 


O'J 


U A 


ic 


1C 


2H 


ir 


1C 


1C 


1C 




LOGOS 10 


0 1 


no 1 1 


01 


20 


FF 


10 


012P 


00 


19 


19 


ID 


19 


DO 


OA 


10 


in 


2 1 


19 


19 


19 


19 




Lor.opp Ip 


0 1 


00 1 1 


0 1 


20 


FP 


IE 


0 1 2P 


00 


IS 


IS 


IE 


16 


OD 


DA 


1 E 


IE 


20 


16 


16 


16 


16 


PH E1001CE 


W!t ITE IF 


01 


*001 1 


01 


2 i 


FP 


1 P 


0 000 


00 


IF 


IP 


CH 


OH 


00 


OA 


1 7 


1 7 


29 


1 p 


1 P 


IP 


IP 




LOGOPP 20 


Oh 


001 1 


01 


20 


PP 


20 


00)0 


2 1 


IS 


IS 


IS 


IS 


HU 


OA 


IE 


IE 


20 


16 


16 


16 


16 


WUTI 


LOGON 21 


Oh 


00 1 1 


0 1 


2D 


PP 


21 


0000 


2 J 


1 9 


19 


1 9 


19 


HO 


UA 


ID 


10 


21 


19 


19 


19 


19 




BOLK I-O 22 


Oh 


0011 


01 


20 


FP 


22 


OOOO 


2 J 


0 A 


OA 


C A 


OA 


HO 


OA 


1 A 


1 A 


22 


J A 


OA 


UA 


UA 


roR 


SI'^OPEPD ?J 


Oh 


00 1 1 


01 


20 


PP 


2 1 


0000 


07 


00 


00 


0 J 


00 


HD 


0 A 


16 


16 


2 t 


00 


OU 


UO 


UO 




INTERACTIVE 2'4 


Oh 


00 1 1 


0 1 


Id 


PP 


2R 


0000 


2 J 


9 7 


20 


10 


OH 


00 


OA 


1 t 


1 7 


29 


1 P 


1 P 


IP 


1 P 


INTERLOCK 


INTERACTIVE 2S 


OS 


001 1 


01 


2D 


PP 


2S 


0000 


2 1 


9 / 


2b 


to 


OH 


HO 


OA 


Id 


lb 


26 


1 P 


IF 


IP 


IP 




INTERACTIVE 26 


Oh 


00 1 1 


0 1 


to 


PP 


26 


0000 


2 i 


2d 


2D 


JP 


OH 


HO 


DA 


IS 


1S 


26 


IP 


1 P 


1 P 


IP 


SET 


BATCH 2 7 


Oh 


001 1 


0 1 


10 


F P 


27 


0 12P 


2 t 


J I 


JS 


2 7 


on 


HO 


UA 


1 B 


1 B 


2 7 


on 


UB 


08 


OB 




BATCH 2H 


OS 


001 1 


01 


to 


PF 


2H 


0 12F 


2 1 


i t 


JS 


2H 


1 1 


rtO 


OA 


ic 


1C 


2b 


1 1 


1 J 


1 J 


1 J 




GROWING 29 


OH 


0026 


OS 


10 


FF 


2H 


noon 


OO 


7A 


2B 


10 


OH 


00 


OA 


1 7 


1 7 


29 


IP 


IP 


IP 


IP 




OFLATING 2A 


0 1 


002S 


Ob 


IH 


PP 


2A 


00)0 


2 1 


9 7 


2H 


to 


)rt 


mD 


UA 


IM 


IM 


26 


IP 


IF 


IP 


1 P 




C.F )W19G 2H 


1 M 


002h 


02 


2C 


PF 


2 3 


GOOD 


00 


2A 


2C 


IP 


IM 


DO 


0 A 


lb 


IH 


26 


IP 


IF 


IP 


IP 


T RT^R^CTI VR 


GPnwiN(i 2C 


1 J 


00 26 


02 


JO 


P P 


2C 


0000 


00 


2P 


20 


u ) 


OH 


00 


OA 


1 s 


IS 


26 


1 p 


1 P 


1 r 


1 P 




GROWING 20 


IS 


noi 1 


01 


a 0 


PP 


20 


OOOO 


00 


ID 


2E 


9 1 


OH 


DO 


0 A 


1 s 


IS 


26 


1 p 


IP 


IF 


IP 


SET 


GROWING 2K 


1 > 


OC 1 i 


J1 


9 0 


PP 


2K 


OUJ ) 


JO 


1 1 


J2 


97 


OH 


00 


OA 


IS 


IS 


26 


IP 


1 P 


IP 


IP 




OILAYIn; 2P 


1 i 


)C2h 


02 


20 


PP 


2P 


0000 


2 J 


9H 


2B 




7M 


HO 


UA 


IS 


IS 


26 


1 r 


1 P 


1 P 


1 P 




DLL A yin; 10 


1 9 


0 0 2S 


01 


\j 


PF 


1 7 


00 )0 


2 J 


9 A 


2C 


9 1 


7H 


HO 


OK 


IS 


IS 


2b 


IP 


IP 


IP 


IP 




Df LAY INC. n 


1 4 


Ou 2h 


0 1 


9G 


FF 


t 1 


0 0 00 


2 » 


9 9 


20 


4 1 


OM 


HO 


OA 


is 


IS 


26 


1 p 


1 P 


IP 


1 P 




Of LAY I NO 12 


1 1 


nail 


71 


9 0 


Pf 


12 


700 » 


2 J 


9H 


20 


9 2 


OH 


DO 


OA 


IS 


IS 


2b 


1 p 


1 P 


IP 


If 




GROWING t| 


1 1 


0026 


01 


10 


PF 


t t 


0 12 P 


DO 


19 


IS 


1 i 


19 


00 


0 A 


IP 


ID 


2 f 


JR 


J9 


J9 


JO 


LO >’'r MG 


OEIAYING »M 


1 1 


00 26 


OH 


IH 


FP 


J9 


0 12P 


2 J 


9C 


i t 


1 1 


IQ 


HO 


UA 


IB 


1 B 


2 7 


J9 


JR 


J9 


JO 




growing is 


Iv' 


0026 


02 


20 


FP 


IS 


0 12K 


00 


J J 


l6 


J » 


19 


JO 


OA 


1 B 


lb 


2 / 


JS 


JS 


JS 


JS 


flXT'H 


GROWING Jt, 


1 J 


0U26 


02 


10 


PP 


Ih 


H12P 


UO 


JH 


J7 


ix 


lA 


00 


0 A 


ic 


1C 


2H 


JA 


JA 


Jl 


JA 




GROWING 17 


1 A 


00 1 1 


0 1 


90 


FP 


J7 


0 12P 


00 


JA 


JH 


to 


IB 


00 


OA 


ic 


1C 


2b 


J B 


JB 


IB 


i B 


SET 


GROWING M 


1 1 


001 1 


01 


90 


PP 


IH 


0 12P 


0 0 


tB 


JC 


tc 


IC 


00 


(1 A 


ic 


1C 


2H 


IC 


IC 


JC 


iC 




OPLAYIN-. 1. 


1 A 


0026 


02 


20 


FP 


JS 


0 12P 


2 J 


SO 


JS 


16 


IS 


DU 


OA 


ic 


1C 


2H 


JS 


JS 


JS 


JS 




OELAYING U 


1A 


0026 


0 1 


JO 


PF 


lA 


b 12P 


2 t 


9P 


J6 


J«» 


1 A 


00 


0 A 


1C 


1C 


2H 


J A 


) A 


J A 


J A 




DELAY IN’. U» 


1 A 


001 1 


01 


90 


F F 


tH 


0 12F 


2 t 


9P 


J t 


1 » 


10 


HO 


OA 


ic 


1C 


2H 


10 


JP 


JB 


JB 




DLlAYING U* 


1A 


00 1 i 


0 1 


90 


FF 


3 * 


0 12P 


2 J 


9F 


J 7 


in 


tc 


HO 


OA 


1C 


1C 


2b 


JC 


JC 


JC 


JC 




GROWING 10 


OS 


0 0 26 


0 1 


10 


FF 


JO 


0 12P 


00 


2A 


2fi 


JE 


OH 


00 


OA 


1 7 


1 7 


29 


1 p 


1 P 


IP 


IP 


AWAIT 


OELAYIKC. IE 


00 


n(i2t» 


01 


10 


F F 


IK 


0 12K 


2 t 


97 


20 


10 


OB 


HO 


0 A 


1 7 


1 7 


29 


IP 


IP 


IP 


If 




'.ROWING IP 


19 


00 1 i 


0 1 


20 


F F 


IP 


0 12P 


00 


2 A 


2C 


9 1 


OH 


00 


OA 


1 b 


lb 


26 


1 p 


1 P 


1 P 


1 f 


INTERACTIVE 


GROWING 90 


1 7 


DOlO 


0 1 


JO 


f P 


0 .» 


0 12P 


00 


2P 


20 


9 i' 


OH 


OD 


0 A 


IS 


IS 


26 


IP 


1 F 


IP 


IP 




GROWING 91 


Ih 


00)9 


0 1 


90 


PF 


9 1 


012P 


00 


to 


2K 


9 6 


OM 


00 


OA 


IS 


IS 


2b 


IP 


IP 


IP 


IP 


SET 


GROWING 92 


IS 


7009 


0 1 


90 


FP 


9 2 


0 1 2P 


•00 


J1 


J2 


9h 


Ob 


00 


OA 


1 s 


IS 


26 


1 p 


If 


IP 


1 P 




DELATING 9) 


19 


00 1 1 


0 1 


20 


FP 


9 i 


0 12P 


2 J 


2H 


2C 


JP 


Ob 


HO 


OA 


10 


1b 


26 


1 p 


IP 


IP 


IP 




DELAYING 99 


19 


0010 


01 


10 


PP 


99 


0 12P 


2 J 


2B 


2D 


90 


Ob 


bO 


0 A 


IS 


19 


2b 


IP 


IP 


IP 


1 f 




DEI. AT INC 9S 


19 


0009 


0 1 


90 


PF 


9S 


0 12P 


2 t 


2C 


2F 


9 1 


Ob 


bO 


OA 


is 


19 


26 


1 p 


1 P 


IP 


IP 




DELATlsr. 96 


19 


0009 


01 


90 


PP 


06 


0 12P 


2 J 


20 


2P 


92 


OH 


bO 


0 A 


19 


IS 


26 


1 p 


1 P 


IP 


IE 




SHRINKING 97 


07 


0026 


10 


OR 


PP 


9 7 


0000 


00 


9B 


2H 


ID 


Ob 


00 


OH 


17 


1 7 


29 


IP 


IP 


If 


If 


in >p[ ss 


OPLAY 1 NG 9fl 


07 


00 26 


10 


OH 


PF 


91 


0000 


2 J 


97 


2H 


JO 


OR 


HO 


Ob 


17 


1 7 


2Q 


1 p 


1 P 


IP 


1 f 


r •. T E*» A C T I V E 


GHR inning 9 9 


1 7 


0026 


01 


10 


FP 


9 1 


0000 


00 


9A 


2C 


90 


Ob 


00 


0 A 


IS 


19 


2b 


1 p 


IP 


IP 


IP 


SET 


SHRINKING 9i 


16 


0026 


02 


20 


FF 


9 A 


00 70 


00 


99 


20 


JF 


OH 


00 


OA 


IB 


1b 


26 


IP 


If 


IP 


IP 




SHRISMN; 90 


IS 


on 26 


OH 


IH 


PP 


93 


0070 


00 


9 7 


2H 


JF 


OH 


00 


OA 


lb 


1b 


26 


1 p 


1 P 


IP 


1 f 




SHRINAING 9C 


1 1 


0 0 2S 


10 


OR 


FP 


9C 


0 12P 


00 


90 


J J 


91) 


90 


00 


OH 


1 0 


1 B 


27 


9 0 


9 0 


0 0 


00 


VI 


OPIATING 90 


1 1 


0C26 


10 


OH 


FP 


9D 


ni2P 


2 t 


9C 


J } 


9C 


9 0 


00 


OD 


10 


IB 


27 


90 


00 


90 


RO 


ur 1 


shrinking 9F 


1 0 


0026 


7 1 


JO 


F P 


9E 


0 12P 


00 


**P 


J 7 


JA 


JA 


00 


OA 


1C 


1C 


2b 


9P 


.9 E 


R E 


R E 


Sri. 


shrinking 9p 


1 A 


102m 


02 


2) 


F F 


9 P 


012P 


00 


SO 


16 


)N 


JS 


00 


OA 


1C 


ID 


2 7 


9P 


9P 


9P 


9P 




shrinking so 


1“ 


002h 


OH 


1 H 


P 


SI) 


01 2P 


00 


9C 


JS 


J9 


19 


00 


OA 


IB 


111 


2 7 


60 


60 


>0 


60 


STAPTI SG 


1 STEP ACT 17 E S 1 


1 7 


OOOH 


V 


20 


FF 


SI 


OOOO 


00 


2B 


S2 


JP 


OH 


00 


OA 


IH 


1 M 


26 


1 f 


1 P 


IP 


If 


ssr 


INTPHACTIV* *>2 


Ih 


0006 


71* 


to 


»P 


s> 


00)0 


1)0 


2C 


S t 


90 


Ob 


ou 


OA 


IS 


IS 


26 


1 P 


1 P 


IP 


If 




1 STSR ACT IV E SI 


IS 


0009 


01 


90 


FP 


s t 


OOOO 


00 


2C 


20 


90 


DH 


00 


0 A 


IS 


IS 


26 


If 


IP 


IP 


IP 



Figure 3. Schedule Table Example 
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48 pages) are established. As each’ program request enters 
from the terminal, it will move upv/ard through these levels 
each time it exceeds its core space limit. Whenever the 
program exceeds its time limit at any of these levels, the core 
space limit of that level is used as the estimate of the pro- 
gram's present working set size. The program is then consi- 
dered to be a longer running program and its future execution 
will be controlled by the looping set of table levels. When- 
ever a program exceeds its largest space limit, the larges 
allowajile working set siz e (64 pages) will be used as_the 
fir* s t e s t.i m a t e for ^ jfu t ure-execut lpn_ un d e r_ .c o n t ro 1. _o f_ t h e 
looping set. 

VJhen a program completes its execution, it is returned 
to the initial s’car’cing set table level to await the next 
input from the terminal. 

2 . The Looping Set 

The looping set of table levels performs the follow- 
ing functions: they use the fields of the schedule table to 
follow a program's working set size by regularly overestimat- 
ing and underestimating its time and core space requirements 
in a minimal fashion in accordance with the principle of 
balanced-core time; they cause the load that is generated by 
long running programs to be spread out in time to allow start- 
ing set entries to be processed rapidly; furthermore, they 
optimize the CPU utilization, and thereby penalize programs ' 
with poor paging characteristics by causing programs v/lth 
minimal paging requirements to be selected to run much more 
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frequently than those with large paging requirements. This 
penalty occurs only v;hen the program has poor locality of 
reference and a large working set size. 



3 . The AWAIT Set 

The AWAIT set Is a special set of table levels re- - 
served for tasks doing tape I/O and other kinds of AWAIT | 
operations. As previously described. In each table level 
there Is an AWAIT extension field, which Is an elapsed time 
Interval during which a program's current working set pages 
are kept In core while the program remains Idle In the AWAIT 
state. Thj.s can cause severe elongations of real-time com- 
pared to virtual time; so that tasks with smaller values of 
virtual time are placed In this set of table levels rather 
than tasks of the same v;orklng set size which are In the 
looping set. 

4 . The Holding Interlock Set 



Is reserved for programs that are currently holding Inter- 
locks on some system resource. (Holding an Interlock mear 
that some program Is using a resource and preventing othei 
programs from using that resource.) Programs In this set 
are given high priority so that the Interlocked resource 



may be quickly released. An Insignificant change In the 
working set size of programs operating In this set Is 
assumed . 



The holding Interlock set Is also a special set that 
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5 . The Walt Ing-For-Interlock Set 
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The wait Ing-for-lnterlock set is another special set 
of levels for programs that are waiting for interlocks to be 
released that are currently being held by other programs 
in the holding interlock set. Until the interlock is re- 
leased, programs in this set of table levels will not usually 
be considered for dispatching. An insignificant change in 
the working set size is also assumed for the interlock set. 

V. EXPERIMENTAL PROCEDURE AND RESULT S 

In order to make a number of test runs using different 
schedule tables, it was first necessary to provide a number 
of programs that would characterize a "realistic" load on 
the system relative to user demands at this school. This 
was necessary since TSS/36O was no longer the current time- 
sharing system in use at this computer installation, and a 
fixed load was needed to make valid performance comparisons. 

A. DEVELOPMENT OP A BENCHMARK 

As was previously discussed, the benchmark design concept 
for general purpose time-sharing systems is not an easy task 
to undertake and is confounded by two factors. The first is 
the variety of demands placed upon the system and second is 
the stochastic behavior of a time-shared system. Arnold D. 
Karush [Ref.l^] presented an excellent discussion of the de- 
velopment of a benchmark design for the ADEPT Time-Sharing 
System at System Development Corporation, and pointed out 
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specific functional variables (compute activity, interactive 

activity, I/O activity, page activity, response allocation, 

user population, and swap activity) that affect system 

performance - specifically response time and throughput. 

Karush discusses two general program design techniques used 

to measure the performance of time-sharing systems - the 

analytical and stimulus methods. The analytical technique 

involves the insertion of probes into the system running 

under actual operating conditions. The stimulus technique 

consists of a "black box." concept and involves applying a 

controlled and measurable set of stimuli to the black box 

to activate the functional variables and then observe the 

effect of the stimuli upon the system. 

The stimulus technique was used to develop the scripts 

for the experimental tests used in this paper; specifically 

a similar set of programs was used by the CP/67 and TSS/36O 

Time-Sharing System comparison group [Ref. 15 ]. 

The final set of benchmark programs used in the test 

runs were as follovjs : 

PLILG - large PL/I compilation 

PLISM - small-sized PL/I compilation 

FORT - Fortran program that is compiled 

FORTEX - Fortran program that is executed 

EDIT - execute routine that edits a simple program and 
files the edited program 

PAGE - Fortran program which executes a large matrix 
multiplication . 
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B. MEASUREMENT TECHNIQUES 



Two types of performance criteria were used to measure 
and judge the improvements in performance. The measurement 
consisted of observing the response times and throughput. 

The benchmark programs used in the tests were written to give 
the real time at the commencement and at the completion of 
a compilation. The throughput was calculated by observing 
the completed compilation or execution of a particular type 
job. The figure obtained by this procedure is called the 
throughput factor and was obtained as follows: 

TPj^ = SS/(RD X NT^) 

where SS = Sample Size (number of completed jobs) 

RD = Run Duration 

NTj^ = Number of terminals running program type i 
In essence, the throughput factor is the reciprocal of the 
time to execute the program, modified by the size of the 
sample . 

C. TOOLS FOR MEASURING PERFORMANCE 

Unfortunately no hardware or software measurement device 
was available to measure resource utilization and performance 
of TSS/360 in this research. A software m.easurement tool 
called SIPE was obtained from IBM, but the required data 
analysis programs could not be obtained. Thus the actual 
measurements could be made, but there was no means of convert 
ing them into meaningful information on resource utilization. 
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The problem of developing a data analysis program to analyze 
the data from SIPE was considered as beyond the scope of this 
research. 

D. PRESENTATION AND DISCUSSION OF RESULTS 

Five test runs were conducted using different schedule 
tables. The results of these tests will be presented and 
discussed in this section. 

The IBM 360 Model 67 configuration of the Naval Post- 
graduate School is shown in Figure ^ and is very similar, but 
not identical, to the IBM T.J. Watson Research Center's Model 
67 conf lgu2’ation which Doherty used for his work. It should 
be noted that when the TSS/36O Time-Sharing System v/as 
implemented at this school for the months previously men- 
tioned, the new IBM V/atson Research Table by Doherty was not 
used. The initial schedule table used in TSS /360 is shown in 
Appendix B (Figure Bl). This table provided poor perfor- 
mance to the user community. Just prior to TSS/36O being 
replaced by the new CP /67 version time-sharing system, the 
new IBM Research Schedule Table arrived and was implemented 
by extending and using important parameters that were never 
used in the old table. A significant improvement in perfor- 
mance was observed. This Improved schedule table is shov;n 
in Appendix B (Figure B 2 ) . In fact about a fifty percent 
increase in utilization was observed, and yet, it was clear 
that more Improvement could be obtained. It was not until 
these tests vjere begun that the ne\i IBM Research Table 
(Figure B 2 of Appendix B) was implemented and tested: 
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Test 1 



1 . 

Test 1 was a preliminary test In which the benchmarlc 
programs (or scripts) were initially used and in which the 
new IBM Watson Research Schedule Table (Figure B2 of Appen- 
dix B) v/as used. The load configuration and performance 
statistics for this test can be seen in Figure 5- Run six, 
operating with a good sampling of all the script except 
paging, produced a mean response of 8 min 37 sec for a large 
PL/1 compilation, ^ min 30 sec for a small PL/1 compilation, 

1 min 8 sec for a Fortran compilation and 48 sec for an 
edit. This test did not provide a heavy load to the system. 

This table, however, did provide better responses than were 
previously observed by the user community when TSS/ 36 O was 
I'uiining on a I'egular basis using the old schedule table. 

2 . Test 2 

Test 2 was conducted, vjlth the same schedule table 
used in Test 1, to provide a more realistic mix with different 
ratios of edlt-to-run (compile and execute) programs and 
heavier load on the system. An important factor to remember 
in scheduling is that almost any scheduling technique will 
show similar results under light loads, but ■ it is only when 
the demand for system resources gets large that scheduling 
differences are clearly indicated. The run durations were 
also lengthened to provide a steadier load on the system. 

The load characteristics and the performance statistics for 

test 2 are shown in Figure 6. Under this change in load, 

the response times have correspondingly increased significantly. 
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LOAD CONFIGURATION/DATA 



RUN NUMBER 


1 


2 . 


3 


4 


5 


6 


7 


PLILG (BIG PL/ 1 ) 


1 


1 


1 


1 


1 


2 


1 


PLISM (SMALL PL/1) 


0 


0 


1 


0 


0 


1 


0 


FORT (FORTRAN) 


1 


2 


1 


2 


3 


1 


3 


EDIT (EDIT SEQ. 


8 


10 


12 


12 


14 


14 


16 


PAGE 
















FORTEX (CPU BOUND) 


2 


2 


3 


3 


3 


3 


4 


RUN DURATION 


16:53 


13:29 


14:52 


17:18 


14 : 32 


16:48 


20:23 



RESPONSE TIME/THROUGHPUT STATISTICS 



PLILG 


MEAN 


1:51 


3:32 


1 — 1 


4:26 


7:54 


8:37 


9:11 


S DEV 


0:07 


0:21 


0: 16 


0:13 


0:11 


0:54 


0:51 


SS 


8 


4 


4 


3 


2 


4 


2 


TP 


0.47 


0.30 


0.27 


0.17 


0.14 


0.12 


0.10 


PLISM 


MEAN 


— 


— 


3:11 


— 


— 


4 : 30 





S DEV 


— 


— 


0:28 


— 


— 


0:58 


— 


SS 


— 


— 


4 


— 


— 


4 


— 


TP 


— 


— 


0 . 27 


— 


— 


0.24 


— 


FORT 


MEAN 


0:l8 


0:36 


0 : 43 


0:46 


1:14 


1 :08 


1 : 28 


S DEV 


0:03 


0 :08 


0 : 09 


0:09 


0:22 


0:17 


0:21 


SS 


49 


4l 


18 


40 


22 


14 


36 


TP 


2.90 


1.52 


1.21 


1.16 


0 . 50 


0.83 


0.59 


EDIT 

RE- 

SPONSE 
TO 6 
EDIT 
COM- 
MANDS 


MEAN 


0 : 30 


0 : 50 


0:50 


0 : 44 

i - - 


1:09 


0:48 


1:12 


S DEV 


0 :02 


0:07 


0:05 


0:04 


0:10 


0 :06 


0:11 


SS 


8 


10 


12 


12 


14 


14 


16 


TP 


.059 


.077 


•061. 


.OSq 


.071 


. or 


^1- 



Figure 5. TSS/ 36 O Test 1 
Loc.d Conditions and Performance Statistics 
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LOAD CONFTGURATION/DATA 


RUN NUMBER 


1 


2 


3 


4 


PLILG (BIG PL/1) 




4 


4 


3 


PLISM (SMALL PL/1) 


3 


6 


5 


5 


FORT (FORTRAN) 


7 


7 


7 


5 


EDIT (EDIT SEQ.) 




4 


4 


8 


PAGE 


- 


- 


2 


2 


FORTEX (CPU BOUND) 


6 


3 


2 


1 


RUN DURATION 


17:32 


15: 42 


37:45 


43:20 


RESPONSE TIME/THROUGHPUT STATISTICS 


PLILG 


MEAN 


21 : 58 


21:48 


35:07 


31:07 


S DEV 


1:25 


3:26 


0:30 


3:39 


SS 




4 


4 


3 


TP 


.0570 


.0635 


.0262 


.0230 


PLISM 


MEAN 


15:38 


17:30 


27:03 


22:02 


S DEV 


1: ^^2 


2:34 


1:31 


3:22 


SS 


4 


6 


8 


6 


TP 


. 0760 


.0636 


. 0423 


.0276 


FORT 


MEAN 


3:12 


3:47 


6:16 


5:12 


S DEV 


:39 


1:03 


2:00 


1:10 


SS 


38 


26 


36 


36 


TP 


.3100 


.2371 


.1361 


. 1660 


EDIT 
RE- 
SPONSE 
TO 6 
EDIT 
COM- 
MANDS 


MEAN 


3:59 


4:56 


11 : 47 


9:26 


S DEV 


— 


— 


- 


- 


SS 


8 


5 


8 


16 


TP 


.0761 


. 1060 


.1055 


.3690 



Figure 6. TSS/ 36 O Test 2 
Load Conditions and Performance Statistics 
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Each test run was conducted under a terminal load of 



27 users. Runs three and four were conducted with heavy 
paging, and as a result, a greater delay was observed in the 
response to a request. It was believed Initially from the 
first two runs that the PL/I compiler characteristics produced 
the heavy load and the poor response, but when several heavy 
paging programs were added to the load, the performance was 
degraded even more. Paging In TSS/36O is handled by disk as 
well as drum, and since disk paging Is slow, this might be 
one of the major problems. 

3. Test 3 

V/hen test 3 was performed, one of the three core 
boxes failed. The results of this test indicate that TSS/36O 
operating v;lth only two core boxes rather than three will 
produce a much lower system performance, so low that the re- 
sults are meaningless for a comparison and are not included 
in this thesis. 

. Test ^ 

Without changing the schedule table of test 2 , runs 
one through four were conducted to see If a different load 
would change the performance characteristics. Run four 
seemed to be a good sampling of the scripts and provided a 
heavy paging load, and the performance characteristics were 
about the same as that in run three of test 2 . The load 
conditions and performance statistics for run four are 
shown in Figure 7 * 
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LOAD CONFIGURATION/DATA 


RUN NUMBER 


1 


2 


3 


H 


5 


PLILG (BIG PL/1) 


2 


2 


2 


2 


2 


PLISM (SMALL PL/1) 


3 


3 


3 


3 


3 


FORT (FORTRAN) 


5 


5 


5 


5 


5 


EDIT (EDIT SEQ.) 


12 


10 


8 


6 


8 


PAGE 


0 


2 


H 


6 


H 


FORTEX (CPU BOUND) 


2 


2 


2 


2 


2 


RUN DURAITION 


22 : 00 


27:53 i 29:07 


C\J 
1 — 1 

0 

cn 


^8:00 


RESPONSE TIME/THROUGHPUT STATISTICS 


PLILG 


MEAN 


19:26 


17:25 


25:12 


25:15 


>^6 min 


S DEV 


0 : 26 


0:09 


1: 38 


l:li8 




SS 


2 


2 


2 


2 


none fin- 
ished (2) 


TP 








* 




PLISM 


MEAN 


12 : 58 


17 : 1^ 


CO 

CO 
1 — 1 


20: 


11:22 


S DEV 


1 : 01 


3:02 


0 : 50 


1:^0 


1:27 


SS 


* 






y. 




TP 


0.291 


0.251 


0.220 


0.192 


0.350 


PORT 


MEAN 


12 : 58 


1 — 1 
( — 1 


18:^8 


20 : 


11:22 


S DEV 


0 :’^6 


0:^8 


0:59 


0:52 


0:52 


SS 


3 


• 3 


3 


3 


9 


TP 


* 










EDIT 

RE- 

SPONSE 
TO 6 
EDIT 
COM- 
MANDS 


MEAN 


3:00 


H:08 


5:25 


6:12 


8:38 


S DEV 


0:19 


0:26 


0:32 


0:26 


2:39 


SS 


2^ 


22 


15 


10 


18 


TP 


0.091- 


0 . 079 


0 . 06^4 


0.055 


0 . 0^6q 



Note: * insufficient statistics. 

Figure 7- TSS/ 36 O Test ^ 

Load Conditions and Performance Statistics 



Run five was conducted with the IBM Research 



Schedule Table patch altered. This modified IBM schedule 
table is shown in Appendix B (Figure B3) • The table para- 
meters that were altered for this run are found in the 
table levels of the Looping Interactive Sets and the Start- 
ing Set of the schedule table, since these sets provide 
areas in which the most improvements in performance could 
be realized. Several fields of the schedule table levels 
were altered, but none were changed drastically. This was 
done so that any degradation to the system which may have 
occurred from changing parameter values could be observed. 
The fields altered and the reasons for the alterations were 
as follows: 

The delta-to-run parameters were increased so that 
the larger working set size programs could get into core 
faster but less frequently and remain there longer with 
larger values of time-slice end. The smaller size programs 
still get priority through the system. 

The AWAIT extension field increases the time 
allowed for the larger size programs to remain on the dls- 
patchable list before being forced to time slice. Since a 
task in AV/AIT status is normally moved from the list of dls- 
patchable tasks, and since this can cause a delay in redis- 
patchlng the task, the idea was to make the AWAIT extension 
large enough to allow for completion of I/O operations. 

A fev/ priority values were changed, since these 
priorities determine the position a task will assume within 
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the list of eligible tasks; that is, low priority numbers 
are given precedence over higher priority numbers . 

The Quantum Count and Quantum length fields were 
altered. These parameters determine the time slice, which 
is dynamic, for tasks assigned to this entry. Time slice 
duration equals Quanta Count times Quantum length x 3.33 
milliseconds. These fields were altered to see the effect 
of the Balanced-Core Time Principle — where the time slice 
duration in terms of CPU execution time for a task is in- 
versely proportional to the working set size in that time 
interval. This v/ill minimize elapsed time that any large 
job can clog memory and allows jobs with good locality to 
progress rapidly. 

The maximum core page residency values (MXCR) have 
been selected to minimize task performance. Trivial and 
many non-trlvlal commands require less than 35(23 hexa- 
decimal) pages allowed in the small conversational levels. 
However, some non-trlvial commands take more pages, causing 
the task to move to other levels. If tasks with the Steal 
Request Flag (SRF) on move into core faster than pages can 
be released, they will exceed the MAXCR limit and be time 
sliced . 

The maximum relocations per quantum field was 
altered. The smaller the value, the greater the guarantee 
the task will be considered I/O bound and its order in the 
dlspatchable list will not change. Therefore, tasks which 
must be serviced can remain on or near the top of the 
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dlspatchable list by assuming them to levels with small MRQ 
values . 

The recompute flag field was altered. If tasks In 
these levels fall behind schedule, they will be given pre- 
ference through the computation of their schedule start 
time. If the preempt flag Is on, a task can be time slice 
ended If a higher priority task Is ready and can not be 
dispatched . 

The scan threshold fields were reduced In value, 
since It v/as felt that a 100^ page stealing value was not 
necessary. The scan threshold Is related to page stealing. 
It should be noted that the stealing mechanism which sets 
the steal flag v/as not Implemented In the old schedule table 
th2.t vjSiS u.S0d dniLtiL3,Hy wdfch t]n0 syst0in. Thiis f'2.0ld V3.1u0 
was altered to allow page stealing. 

As shown In Figure 7j by primarily Increasing the 
delta-to-run and quantum fields, the large working size 
programs (PLILG) were penalized In their response times, 
whereas an Improvement In response was observed In small 
PL/I and Fortran compilations. However, In the EDIT pro- 
grams, response times were even worse during this run than 
before and the throughput factor went down. 

5. Test 5 

The last test was conducted using three different 
schedule tables. The characteristics for this test are 
shown In Figure 8. Unfortunately, there were only 20 ter- 
minals loading the system, since the other terminals were 
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inaccessible or inoperable. The time was also limited for 
these test runs so that the durations were shorter than was 
desirable. The schedule table for run three is shown in 
Figure B4 of Appendix B. The parameters that vjere altered for 
the schedule table for run three were the delta-to-run fields, 
which were set to very large values, and the quantum fields. 
Although the load was not as heavy as that of test 4, these 
test runs do show significant improvement, and the increased 
performance is the result of judiciously altering these para- 
meters. The response times for PLILG programs for runs tv/o 
and three were about the same, v/hl].e the response time for 
FORT programs was better for run one than for two and three. 
H 0 WPVGT 3 It- is GxpcctGd. thst ir 2 . h 02 ,vi 0 r lo 2 .d h 2 .d b 00 n 
placed on the system, run three would have provided the bet- 
ter performance statistics. The response times for small 
size PL/I programs, and EDIT programs for run three shovj bet- 
ter response statistics, and the response time for FORT 
programs for run three shows an Increase over run tvjo. 

Figures 9jl0 and 11 shovj the difference in response times 
for each of these runs. The throughput factor could not be 
obtained for big and small PL/I programs, but run three 
shov 7 S an increase in throughput over run tv70 for FORT pro- 
grams but about the same as run one. For EDIT programs, run 
three shows an increase in throughput over run one and two. 
Figures 12 and 13 shovj the difference in throughput. 
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LOAD CONFIGURATION/DftTA 


RUN NUMBER 


1 

APP B FigB2 


2 

APP B Fig B3 


3 

APP B Fig B4 


PLILG (BIG PL/I) 


1 


1 


1 


PLISM (SMALL PL/I) 


2 


2 


2 


PORT (FORTRAN) 


5 


5 


5 


EDIT (EDIT SEQ.) 


4 


4 


4 


PAGE 


3 


3 


3 "" 


PORTEX (CPU BOUND) 


2 


2 


2 


RUN DURATION 


00 

0 


25:43 


00 

1 — 1 


RESPONSE TIME/THROUGHPUT STATISTICS 


PLILG 


MEAN 


44:06 


20:50 


20:50 


S DEV 








SS 


1 


1 


1 


TP 








PLISM 


MEAN 


32:08 


CO 

C\J 
( — 1 


t — 1 

CTi 

cr 


S DEV 


2:51 


:11 


:27 


SS 


2 


2 


2 


TP 






* 


FORT 


MEAN 


:54 


1 — 1 


1:28 


S DEV 


:15 


:31 


:02 


SS 


93 


30 


38 


TP 


.62 


.3 


.60 


EDIT 

RE- 

SPONSE 
TO 6 
EDIT 
COM- 
MANDS 


MEAN 


6:26 


8:36 


6:13 


S DEV 


:07 


:04 


:06 


SS 


22 


9 


8 


TP 


.14 


.11 


.21 



Note: * Insufficient statistics 

Figure 8 . TSS/ 36 O Test 5 
Load Conditions and Performance Statistics 
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of Test 5 
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Figure 10. Response Time Comparisons for Small PL/I 
Compilations of Test 5 
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Figure 11. Response Time Comparisons for EDIT Script of 
Test 5(6 EDIT Commands ) 



THROUGHPUT 

FACTOR 




NUMBER OF TASKS 



Figure 12. Throughput Comparisons for Fortran Compilations 
of Test 5- 
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Figure 13. Throughput Comparisons for EDIT Script ( 
Commands ) of Test 5 
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VI. CONCLUSIONS AND REC 0 MMI:NDATI 0 NS 



The objectives of this paper were to organize all avail- 
able literature regarding improvement of performance measures 
and techniques for the TSS/36O Time-Sharing System Schedule 
Tables and to show that these principles and concepts could 
be substantiated by performing experimental tests on the 
computer. As a result of altering the parameters of the 
TSS/360 schedule table, improved performance over the initial 
system performance, when the TSS/36O system was in full ope- 
ration, was observed. From these tests it is evident that 
because of differences in the user community and in hardware 
configurations it is necessary that certain parameters in the 
table-driven scheduler be set for each installation to improve 
its system performance and thus maintain a satisfied user 
community . 

It has been shown by these tests that the Naval Postgra- 
duate School's Model 67 computer could support about 20-25 
simultaneous users using a modified IBM Research schedule 
table, vihile maintaining a fair response to the trivial re- 
quests, and simultaneously servicing large users rather well. 
With more work on the schedule tables, better service could 
be provided for a greater simultaneous load. Once the TSS/36O 
Time-Sharing System was removed as the installation's time- 
sharing system, the time available for testing in this project 
v;as restricted. Many more valuable tests remain to be 
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performed to eventually optimize the performance of the sys- 
tem through the judicious alteration of the parameters of the 
TSS/360 table-driven scheduler. 

There v;ere many fields of the TSS/36O schedule table that 
were not varied and tested. For example, during the last test 
a table was designed to test the page drum mechanism, but 
since this mechanism was not yet Implemented into the soft- 
ware, this table could not be employed. The present values 
of the schedule table at this installation show a 0000 default 
to the system calculated, minimum number of pages on disk for 
all users. This value could be increased to allov; some 
tasks to be allocated greater space on drum in order that 
fewer of their pages have to be moved from drum to disk. 
Nielson [Ref.lbj in his simulation studies of time-sharing 
systems, showed that disk paging can be very slov/ and can 
reduce system performance substantially, and proposes that a 
drum be used in place of the disk. Since this installation 
used both drum and disk paging, an alternative solution could 
be to purchase another drum for paging. Also, revision of 
the disk management .algorithm could be made. 

As mentioned at the outset of this paper, a more flexible 
approach to evaluating the effects of changing different 
schedule table parameters on the performance of the system 
would have been the simulation approach rather than an analy- 
tical approach. Hov;ever, such a simulation model would have 
to be limited in terms of expensiveness of design and running 



time. AlsOj there is always the very difficult problem of 
validating the simulation model. 

Prom the tests conducted in this paper^ attempting to 
optimally tune the scheduler by trying various schedule tables 
in the proper type of environment is not an easy process. 

There were many factors which limited more speedy progress in 
tuning the scheduler to the job load of this school's environ- 
ment. The benchmark that was implemented for the tesbs may 
not have accurately represented the user community, although 
a great effort in this direction was made. Since loads are 
constantly changing, it is important to develop a methodology 
for automatically producing scripts that are characteristic 
at this installation and then to verify that they are accurate. 

The use of the TSS/36O software measurement technique, 

SIPE [Ref. 17] j would have been very valuable and helpful in 
establishing a good benchmark for developing, evaluating, and 
Improving the interactive system. SIPE and its data-reduc- 
tlon program could also have been very helpful in evaluating 
changes to the schedule tables and the effects on system 
performance. These measurement tools could also provide 
valuable statistics about each task as it is being processed 
by the system. Software counters, as Doherty used, could 
also provide Information about each task as it migrates 
through various levels of the schedule table to more accu- 
rately verify the principles of working set size and balanced 
core time. De Meis and V/elzer [Ref.l 8 ] established by exper- 
imental means in developing RCA's Time Sharing Operating 
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System (TSOS) that by using certain measurement devices, the 
working set size and balanced-core time of programs can be 
monitored and verified. 

Although SIPE produces some degradation to the system, 
this is not considered serious. The only way to monitor a 
system without altering its operation is by external hard- 
ware monitors. Schulman [Ref. 19 ], for example, discusses a 
hardware monitor (SPAR) that also is used to measure TSS/36O 
and that does not degrade that system. Another tool that 
has been extremely useful in TSS/36O evaluation and improve- 
ment of performance is the instruction-time trace monitor 
(ITM) [Ref. 20 ] which is a combination of software and hard- 
ware. V/lth the aid of these additional measuring devices, 
it is believed that many more i mprovem.ents could be made to 
the performance of TSS/36O by further adjustment of the 



entries in the schedule table. 



APPENDIX A 



SCHEDULE TABLE PARAMETER DEFINITIONS 
LE''/EL (STELEVEL), 1 BYTE 

Relative entry number in schedule table. The level num- 
ber is used to relative address within the schedule table. 

PRIORITY (STEPRIOR), 1 BYTE 

The priority of a level in conjunction with the Schedule 
Start Time (SST) is used to govern the allocation of CPU re- 
sources to a task. Only those tasks brought into .the dis- 
pat chable list can increase in core usage. Zero is the 
highest priority. V/hen seeking to bring a task into the dis- 
patchable iist, the highest priority task behind schedule is 
chosen. If no tasks are behind schedule, the highest priority 
task is chosen. 

QUANTUM LENGTH (STETSVAL), 2 BYTES 

The quantum length is the numbei* of time units (one 
quantum) a task will be dispatched or the amount of time to 
be used as a factor in determining how long a task will be 
allowed to run before time-slice end. One unit represents 
3.33 milliseconds. A quantum represents the maximum virtual 
memory time that a task will be dispatched. The system v/111 
then make a decision as to whether the task may have more CPU 
time based on the number of quanta used (see STEQUANT) or 
Interrupted by a time-slice end. 
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MAXIMUM NUMBER OF QUANTA (STEQUANT), 1 BYTE 

This field represents the maximum number of quanta (STES“ 
VAL) a task may use or receive when it is in execution before 
a time-slice must occur. 

MAXIMUM PAGES (STEMAXCR) , 1 BYTE 

This field represents the maximum number of private 
physical pages allowed in core before a time-slice end or page 
steal will occur. (see SCAN THRESHOLD) 

MAXIMUM DISK I/O OR PAGE READS (STEMAXRD) , 2 BYTES 

This field represents the maximum disk reads or writes j 
or maximum number of page relocations a task will be allov/ed 
before a time-slice end will occur. 

SCAN THRESHOLD (STEST) , 1 BYTE 

If the steal request flag (STESRF) is on, the resident 
supervisor will release some of a task's pages when the page 
count equals STEMAXCR (maximum core page residency values) . 

The scan threshold is the percentage of STEMAXCR pages to be 
retained. The scan threshold is a percentage specified in 
hexidecimal (i.e., 80 % = 80 base 10 = 50 base l6). V/hen steal- 
ing occurs, the task is not time-sliced, but stays in the 
dispatchable list. However, the schedule table entry in the 
TSI is changed to the value specified in STENSL (next steal 
level ) . 
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PULSE LEVEL (STEPULSE), 1 BYTE 

This field represents the schedule table level entry to 
be used if the pulse service is requested by the user. The 
pulse service allows the user to request a level change. 

AV/AIT EXTENSION (STEAV/TEC) , 2 BYTES 

This field represents the maximum time that a task, issu- 
ing an AV/AIT service, is allowed to remain in the dispatch- 
able list while waiting for an I/O operation to be completed. 
The units are 3.33 milliseconds. If the I/O operation has 
not completed before the time limit specified, the task is 
time-sliced . 

DELTA-TO-RUN TIME (STEDELTA) , 1 BYTE 

Specifies the real time interval av which a uasK is ro 
be given a slice of CPU time. This field specifies a factor 
which is used to calculate a new Schedule Start Time (SST) 
for a task as it moves from one state to another; l.e., as 
the task becomes ready, in AV/AIT or in TV/AIT. The value in 
this field is multiplied by 852.5 milliseconds and may be 
combined with the master clock time or the old Scheduled 
Start Time if the old SST is negative to determine the task's 
new SST. If delta-to-run equals zero, the SST is set to 
zero and the task is automatically placed behind schedule, 
(see RECOMPUTE FLAG) 
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(TSE) TIME-SLICE END (STETSEND) , 1 BYTE 

This field represents the schedule table level entry to 

be used when a time-slice end occurs because of the maximum 

number of quanta (STEQUANT) or a maximum disk I/O (STEMAXRD) 
has been reached. 

MAXIMUM PAGES TSE (STEMPRE) , 1 BYTE 

This field represents the schedule table level entry to 

be used when a tmme-slice end occurs because of the maximum 

pages in core (STEMAXCR) has been reached, 

TWA IT TSE (STETWAIT), 1 BYTE 

This field represents the schedule table level to be 
Used after a time-slice end occurs because the TWAIT service 
has been used. 

AWAIT TSE (STEAWAIT), 1 BYTE 

This field represents the schedule table level entry to 
be used after a time-slice end occurs because the AWAIT service 
has been used. 

RECOMPUTE FLAG (STERCMP), 1 BIT 

If the recompute flag is on, the task's Scheduled Start 
Time is computed to place the task back on schedule as des- 
cribed above under delta-to-run (STEDELTA) . If the flag 
is off, past performance (if behind schedule) is taken into 
account by calculating SST as the present time plus delta- 
to-run minus the amount behind schedule on the previous 
time-slice. NOTE: When a task enters the eligible list 
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directly from the dispatchable list, the schedule start time 
is calculated as if the recompute flag is off. 

PRE-EMPT FLAG (STEPRMPT) , 1 BIT 

A task on the dispatchable list whose pre-empt flag is on 
may be forced to time-slice end so as to make room for a task 
from the eligible list having a higher priority. 

STEAL REQUEST FLAG (STESRI) , 1 BIT 

A task on the dispatchable list whose steal request flag 
is on will have pages released (stolen) when its private 
pages in core reach the STEMAXCR limit . If pages .are brought 
in faster than they can be released so that the STEMAXCR 
limit is exceeded, the task will be time-sliced. 

MAXIMUM PAGE RELOCATIONS PER QUANTUM (STEMRQ), 1 BYTE 

Specifies the maximum number of page relocation inter- 
ruptions allowed per quanta before the task is declared pag- 
ing boundj i.e., a task is considered to be execute bound if 
its number of page relocations per quantum is less than or 
equal to STEMRQ. Execute bound tasks are placed at thb end 
of the dispatchable list to allow non execute bound tasks to 
overlap their paging I/O with execute bound tasks. 

HOLDING INTERLOCK CHANGE LEVEL (STEHLCK), 1 BYTE 

This field represents the schedule table level entry to 
be used when a time-slice end occurs (except for AWAIT or 
TWAIT) and the task is holding a Virtual Access Method (VAM) 
interlock . 
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LOW-CORE HOLDING INTERLOCK (STELCHL) , 1 BYTE 

This field represents the schedule table level entry to 

be used when a time-slice end occurs because of low-core and 

the task Is holding a Virtual Access Method (VAM) Interlock. 

WAITING ON INTERLOCK CHANGE LEVEL (STEWLCK), 1 BYTE 

This field represents the schedule table level entry to 

be used when a time-slice end occurs and the task Is waiting 

on an interlock. 

CONVERSATIONAL WRITE ONLY (STECWO) , 1 BYTE 

This field represents the schedule table entry to be used 
when a write without response message Is sent to the terminal. 
The level change occurs without a time-slice end. 

LOW CORE FORCED TIME-SLICE END (STELCF) , 1 BYTE 

This field represents the schedule table entry to be 
used when a task is forced to time-slice end for low-core 
and it Is not holding an Interlock. 

PREJUDICE CATEGORY 3 (STEPRJ3), 1 BYTE 

This field Is not used In the system. 

NEXT STEAL LEVEL (STENSL) , 1 BYTE 

This field represents the schedule table entry to be used 
v/hen stealing occurs. The task Is not time-sliced. 

DRUM SHARE (STEDSH), 2 BYTES 

This is the number of drum pages reserved for a task. 

There are about 500 pages available after startup on a one 
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drum system and 1^00 pages on a two drum system. In general 
the number of a task's private pages on drum is a function o 
the number of tasks logged on, the number of drums, and the 
time since the last time-slice. If the number of unassigned 
drum pages falls below a pre-determined limit, some pages 
are moved from drum to disk. Each task receives a system 
calculated minimum drum space. The drum share field allov^^s 
some tasks to keep a large drum share. A value of zero 
defaults to the system calculated minimum. 
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SCHEDULE TABLES USED FOR DIFFERENT TESTS 
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Figure 1 ^ Bl. Old TSS/36O Schedule Table 
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Figure 1^ B3- Test 4 (Run .5) Schedule Table Modifications 
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Figure B^l . Test 5 
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